Илья Медведовский - Атака на Internet

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

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

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

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

Направленный шторм запросов на ОС Windows NT 4.0

В связи с особой популярностью у пользователей операционной системы Windows NT мы решили описать эксперименты с данной ОС отдельно. Анализировалась реакция Windows NT 4.0 build 1381 с установленным Service Pack 3 и дополнительным ПО в составе MS IIS 3.0, MS Exchange 5.0, MS SQL 6.5, MS RAS на компьютере со следующей аппаратной конфигурацией: процессор – Pentium 166 MMX, ОЗУ – 32 Мб, HDD – 2 Гб, сетевая карта – 32-разрядная (фирмы 3COM).

Эксперимент осуществлялся следующим образом. На соответствующий порт атакуемого сервера в цикле TCP SYN отправлялось 9 500 запросов в секунду, что составляет около 50 % от максимально возможного количества сообщений при пропускной способности канала 10 Мбит/c. В результате было выведено пороговое значение, определяющее число запросов в секунду, при превышении которого удаленный доступ к серверу становится невозможным.

Во время шторма TCP-запросов на указанные порты наблюдалась следующая реакция системы:

• замедлялась работа локального пользователя (нажатия на клавишу обрабатывались 1-10 секунд, менеджер задач показывал 100-процентную загрузку процессора);

• удаленный доступ по сети к атакуемому серверу на любой порт оказывался невозможным;

• на сервере из-за нехватки памяти переставали запускаться любые процессы (появлялись сообщения «Нет системных ресурсов»);

• при шторме на 139-й порт с довольно большой вероятностью (около 40 %) система через некоторое время «зависала» («синий экран»);

• после перезагрузки сервера при постоянно идущем шторме на 139-й порт сервер, как правило, «зависал» (вероятность более 50 %);

• при попытке обращения с консоли сервера в сеть возникали многочисленные ошибки (пакеты не передавались, система «зависала»).

После прекращения шторма запросов TCP SYN у атакуемого NT-сервера наблюдалась следующая реакция:

• из-за нехватки памяти переставали запускаться любые процессы (появлялись сообщения «Нет системных ресурсов»). Удаленный пользователь не всегда мог получить необходимую ему информацию, даже если удаленный доступ к портам сервера был возможен (HTTP-сервер при попытке обращения к ссылке возвращал ошибку);

• при попытке вызова Менеджера задач на локальной консоли система «зависала»;

• иногда наблюдались отказы в обслуживании при любом удаленном доступе.

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