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

Такую атаку можно было предсказать еще лет двадцать назад, когда по­явилось семейство протоколов TCP/IP: ее корни находятся в самой инф­раструктуре сети Internet, в ее базовых протоколах - IP и TCP. Но каково же было наше удивление, когда выяснилось, что на информационном . WWW-сервере CERT (Computer Emergency Respone Team) первое упоминание об удаленном воздействии такого рода датировано только 19 сентяб­ря 1996 года! Там эта атака носила название «TCP SYN Flooding and IP Spoofing Attacks» («наводнение» TCP-запросами с ложных IP-адресов). Другая разновидность атаки «отказ в обслуживании» состоит в передаче на атакуемый хост нескольких десятков (сотен) запросов TCP SYN в се­кунду (направленный мини-шторм TCP-запросов) на подключение к сер­веру, что может привести к временному (до 10 минут) переполнению оче­реди запросов на сервере (см. атаку К. Митника). Это происходит из-за того, что некоторые сетевые ОС обрабатывают толь­ко первые несколько запросов на подключение, а остальные игнорируют, Таким образом, получив N запросов на подключение, ОС сервера ставит их в очередь и генерирует соответственно N ответов. Затем в течение опреде­ленного промежутка времени (тайм-аут < 10 минут) сервер будет дожи­даться сообщения от предполагаемого клиента, чтобы завершить handshake и подтвердить создание виртуального канала с сервером. Если атакующий пришлет такое количество запросов на подключение, которое равно макси­мальному числу одновременно обрабатываемых сервером сообщений, то в течение тайм-аута остальные запросы будут игнорироваться и установить связь с сервером не удастся.

Мы провели ряд экспериментов с направленным штормом и направлен­ным миништормом запросов на различных по вычислительным мощнос­тям компьютерах с разными операционными системами.

Тестирование направленным штормом запросов TCP SYN, проводимое на различных сетевых ОС в экспериментальных 10-мегабитных сегментах сети, дало следующие результаты: все описанные далее атаки осуществлялись по определенной методике. Подготавливался TCP-запрос, который при помощи специально разрабо­танной собственной программы в цикле передавался в сеть с соответству­ющими задержками (вплоть до нулевой) между запросами. При этом цик­лически изменялись такие параметры запроса, как порт отправителя и значение 32-битного идентификатора SYN. IP-адрес отправителя запро­са был выбран так, чтобы, во-первых, этот хост в настоящий момент не был активен в сети и, во-вторых, чтобы соответствующий маршрутизатор, в чьей зоне ответственности находится данный хост, не присылал сообще­ния Host Unreachable (Хост недоступен). В противном случае хост, от име­ни (с IP-адреса) которого посылался запрос TCP SYN, получив «неожи­данный» ответ TCP АСК от атакуемого сервера, перешлет на него пакет TCP RST, закрывая таким образом соединение.

При передаче по каналу связи максимально возможного числа TCP-зап­росов и при нахождении кракера в одном сегменте с объектом атаки ата­куемые системы вели себя следующим образом: ОС Windows 95, установ­ленная на 486DX2-66 с 8 Мб ОЗУ, «замирала» и переставала реагировать на любые внешние воздействия (в частности, нажатия на клавиатуру); ОС Linux 2.0.0 на 486DX4-133 с 8 Мб ОЗУ также практически не функциони­ровала, обрабатывая одно нажатие на клавиатуре примерно 30 секунд. В результате к этим хостам невозможно было получить не только удален­ный, но и локальный доступ.

Не менее интересным было поведение атакуемых систем после снятия воздействия: ОС Windows 95 практически сразу же после прекращения ата­ки начала нормально функционировать; в ОС Linux 2.0.0 с 8 Мб ОЗУ, по-видимому, переполнился буфер, и более получаса система не функциони­ровала ни для удаленных, ни для локальных пользователей, а занималась только передачей ответов на полученные ранее запросы. CyberGuard сразу же после снятия воздействия стал доступным для удаленного доступа.

Если кракер находился в смежных сегментах с объектом, то во время атаки ОС Windows 95 на Pentium 100 с 16 Мб ОЗУ обрабатывала каждое нажатие с клавиатуры примерно секунду, ОС Linux 2.0.0 на Pentium 100 с 16 Мб ОЗУ практически «повисала» - одно нажатие за 30 секунд, зато после снятия воздействия нормальная работа возобновлялась.

Не нужно обманываться, считая, что ОС Windows 95 показала себя с лучшей стороны. Такой результат объясняется следующим: Windows 95 - операционная система, не имеющая FTP-сервера, а следовательно, ей не нужно было сохранять в памяти параметры передаваемого TCP-запро­са на подключение к этому серверу и дожидаться окончания handshake.

    Таким образом, учитывая аппаратные средства сервера octopus.lstu (Olivetti 80286) можно без труда осуществить на него DoS атаку. Даже если локальная сеть будет загружена. Можно предположить, что и остальные сервера университета могут быть «обездвижены» таким способом. Например сервер кафедры прикладной математики: IBM 486DX66 16RAM. По аппаратной части серверы кафедры АСУ (здесь не имеется ввиду octopus.lstu) более устойчивы к DoS атаке.

Превышение максимально возможного размера IP-пакета, или Ping Death

В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка и длина ноля данных в IP-пакете. Так как минимальный раз­мер IP-заголовка - 20 байт (максимальный - 60), то соответственно раз­мер данных, передаваемых в одном IP-пакете, не может превышать 65 535- 20 = 65 515 байт. А что будет, если превысить это число? Тестировать свои программы на предельных критических значениях -стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (бу­фера, стека, переменной и т. д.). Но вернемся к IP. В принципе ничто не мешает атакующему сформиро­вать набор фрагментов, которые после сборки превысят максимально воз­можный размер IP-пакета. Собственно в этой фразе и сформулирована основная идея данной атаки.

Итак, 18 декабря 2000 года на информационном сервере СЕКТ появи­лись сообщения о том, что большинство сетевых операционных систем, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допу­стимое значение, в этих ОС переполняется буфер или переменная, в ре­зультате система «зависает» или перезагружается, то есть налицо отказ в обслуживании. Был приведен и список потенциально опасных платформ:

• Berkeley Software Design, Inc. (BSD);

• Computer Associates, Intl. (products for NCR);

• Cray Research;

• Digital Equipment Corporation;

• FreeBSD, Inc.; ' Hewlett-Packard Company;

• IBM Corporation;

• Linux Systems;

• NEC Corporation;

• Open Software Foundation (OSF);

• The Santa Cruz Operation, Inc. (SCO);

• Sun Microsystems, Inc.

Мы с удивлением прочитали этот перечень операционных систем на различных платформах, а потом принялись за эксперименты. Наше глу­бочайшее изумление вызвал тот факт, что элементарную ошибку пере­полнения буфера в модуле IP ядра ОС за почти 20 лет активного функ­ционирования протокола IP разработчики сегодняшних систем до сих пор не замечали. Поэтому мы позволили себе не поверить столь уважае­мой организации, как CERT. Но прежде чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке (#"1.files/image007.gif">Подведем итоги.

  Учитывая все вышесказанное, я думаю, что студентам кафедры АСОИУ уже сейчас не представляется никакой сложности для несанкционированного доступа к терминалам серверов с правами администраторов (причем это не необоснованное высказывание). Другой вопрос – целесообразности всего этого. Я думаю что не стоит проверять все вышесказанное на практике в целях своей же безопасности.

   В целом, вычислительная сеть университета администрируется весьма неплохо, нужно отдать должное системным администраторам. На серверах стоят последние версии операционных систем. Однако на chuck.stu.lipetsk.ru почему-то у обычных пользователей нет прав на компилирование Си программ. Почему? Может это и есть слабое звено в администрировании, или это еще одна предосторожность администратора? Хотя на tomcat.am.lstu обычным смертным разрешено…

   Вообще-то взлом octopus.stu.lipetsk.ru был бы неуважением своей же кафедры. Ведь та защита которая там присутствует направлена не для того, чтобы предотвратить проникновение злоумышленника, а для элементарной защиты от неопытных пользователей. 

ПРИЛОЖЕНИЕ.

В целях безопасности, приводим только фрагменты программы. Файл john.c

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <sys/stat.h>

#include "arch.h"

#include "misc.h"

#include "params.h"

#include "path.h"

#include "memory.h"

#include "list.h"

#include "tty.h"

#include "signals.h"

#include "idle.h"

#include "common.h"

#include "formats.h"

#include "loader.h"

#include "logger.h"

#include "status.h"

#include "options.h"

#include "config.h"

#include "bench.h"

#include "charset.h"

#include "single.h"

#include "wordlist.h"

#include "inc.h"

#include "external.h"

#include "batch.h"

#if CPU_DETECT

extern int CPU_detect();

#endif

extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;

extern struct fmt_main fmt_AFS, fmt_LM;

extern int unshadow(int argc, char **argv);

extern int unafs(int argc, char **argv);

extern int unique(int argc, char **argv);

static struct db_main database;

static struct fmt_main dummy_format;

static void john_register_one(struct fmt_main *format)

{

                if (options.format)

Страницы: 1, 2, 3