Обнаружение вторжений

Атаки

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

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

Нарушения политики

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

• Общий доступ к файлам (Gnutella, Kazaa и т. д.).
• Обмен мгновенными сообщениями.
• Сеансы Telnet.
• Команды "r" (rlogin, rsh, rexec).

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

Выбор метода обработки различных нарушений политики зависит от внутренних политик и процедур, имеющих место в организации. Тем не менее, необходимо разъяснить все моменты системному администратору или ответственному лицу, чтобы ему стала ясна суть политик организации.

Подозрительные события

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

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

Внимание!

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

Исследование подозрительных событий

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

1. Идентифицировать системы.
2. Записывать в журнал сведения о дополнительном трафике между источником и пунктом назначения.
3. Записывать в журнал весь трафик, исходящий из источника.
4. Записывать в журнал содержимое пакетов из источника.

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

Примечание

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

1. Идентификация систем

Первым шагом при исследовании подозрительной активности является идентификация участвующих в действии систем. Эта процедура может заключаться в преобразовании IP-адресов в имена узлов. В некоторых случаях имя узла найти не удается (система не имеет записи DNS; это клиент DHCP; удаленный DNS-сервер находится в неактивном состоянии и т. д.). Если поиск DNS оканчивается неудачей, то следует попытаться идентифицировать узел другими способами, например, поиском в реестре American Registry of Internet Numbers (ARIN) по адресу http://www.arin.net/, в Internic по адресу http://www.networksolutions.com/ или в других каталогах интернета. Утилиты, такие как Sam Spade (находятся по адресу http://samspade.org/), также помогут в данном случае. Невозможность идентификации источника или пункта назначения подозрительных действий не является достаточным доказательством того, что событие в действительности является атакой. Аналогично, успешная иденти фикация систем не является достаточным доказательством "безобидности" обнаруженных действий.

Примечание

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

2. Запись в журнал дополнительного трафика между источником и пунктом назначения

Одно-единственное отдельное событие (например, нарушение протокола IP) может не представлять полную информацию о трафике между двумя системами. Иными словами, необходимо понимать контекст подозрительных действий. Хорошим примером здесь служит признак атаки Sendmail WIZ. Этот признак идентифицирует попытку использования команды WIZ в программе Sendmail. Данное событие безопасности идентифицирует любое вхождение команды WIZ в сообщении. Если команда WIZ присутствует в теле сообщения, то это определенно не попытка вторжения. Понимание контекста события помогает определять ложные срабатывания.

Настройте IDS на отслеживание всего трафика между источником подозрительной активности и пунктом назначения. В качестве примера используйте таблицу 13.3.

Теперь зададимся вопросом, что же это все нам дает. Во-первых, мы получаем представление о другом трафике, имеющем место между источником и пунктом назначения. Если бы пакет WIZ был единственным трафиком между двумя системами, из этого можно было сделать вывод о том, что это похоже на попытку проникновения в систему. Напротив, если наблюдается большое число трафика SMTP (почты) между двумя системами, то, скорее всего, это обычный легитимный почтовый трафик.