Управление IDS
Концепция обнаружения вторжений - уже не новинка в области информационной безопасности. Тем не менее, до недавнего времени дела обстояли несколько иначе, пока на коммерческом рынке не появились системы IDS. На момент написания этой книги различные производители предлагали свои сетевые и узловые системы IDS. Также существует ряд бесплатных систем обнаружения вторжений.
Перед принятием в организации решения об использовании IDS (будь то коммерческая система или некоммерческая) руководство организации должно четко определить цели применения программы. Правильная настройка и управление IDS требует больших усилий, и эти усилия следует как можно более эффективно использовать для обнаружения атак (посредством реализации хорошей программы по обеспечению безопасности).
С учетом сказанного выше, если принято решение о применении IDS, то для успешной реализации программы необходимо обеспечить наличие всех нужных ресурсов. Если цели программы IDS включают возможность мониторинга в круглосуточном и ежедневном мониторинге атак, сотрудникам организации понадобится быть "наготове" круглые сутки семь дней в неделю. В то же время системным администраторам потребуется работать с сотрудниками, ответственными за безопасность, для определения успешного или безуспешного проведения атаки и, в случае успешной атаки, для определения метода обработки инцидента. В идеальном случае процедура по обработке инцидента должна быть создана и протестирована перед применением системы IDS.
О чем может сообщить система IDS
Система обнаружения вторжений может только выдавать отчеты о тех событиях, на обнаружение которых она настроена. Конфигурация IDS состоит из двух компонентов. Первым из них являются признаки атак, запрограммированные в системе. Второй компонент - любые дополнительные, определенные администратором, события, также представляющие интерес. Среди этих событий могут быть определенные типы трафика или сообщений журнала.
Посредством включения в конечный продукт признаков атак поставщик или разработчик системы по-своему интерпретирует уровень важности указанных событий.
Степень важности, присваиваемая определенным событиям в той или иной организации, может быть совершенно иной, нежели та, которую предусмотрел разработчик. Может понадобиться изменить параметры по умолчанию для некоторых признаков или просто отключить признаки, не применимые к организации.
Примечание
Следует иметь в виду, что система IDS будет выдавать предупреждения только о тех событиях, которые она обнаружит. Если на системе, отслеживаемой датчиком HIDS, не заносятся в журнал определенные события, то датчик HIDS не будет их распознавать. Аналогично, если датчик NIDS не может "видеть" определенный трафик, он не выдаст предупреждение даже в том случае, если событие произойдет.
С условием правильной конфигурации IDS можно привести четыре типа событий, о которых будет сообщать система IDS.
- События исследования.
- Атаки.
- Нарушения политики.
- Подозрительные или необъяснимые события.
Большая часть времени будет уделяться исследованию подозрительных событий.
События исследования
События исследования представляют собой попытки атакующего собрать данные о системе перед непосредственным проведением атаки. Эти события можно разделить на пять категорий.
- "Скрытое" сканирование.
- Сканирование портов.
- Сканирование "троянских коней".
- Сканирование уязвимостей.
- Отслеживание файлов.
Большая часть этих событий происходит в сети, в основном, они исходят из интернета и направлены на системы с внешними адресами.
События исследования являют собой попытки сбора информации о системах. Они не являются событиями, воздействующими на систему. Некоторые коммерческие IDS воспринимают события исследования как события высокого приоритета. С учетом того, что эти события не наносят ущерба системе, такой подход можно счесть неразумным.
Примечание
Источником подобного трафика может быть и другая система-жертва, захваченная злоумышленником, поэтому данную информацию следует сообщать системным администраторам этого узла.
Скрытое сканирование. Скрытое сканирование - это попытки идентификации систем, присутствующих в сети, с целью предотвратить обнаружение системы, с которой будет проводиться атака.
Этот тип сканирования будет определяться датчиками NIDS как половинчатое сканирование IP или скрытое сканирование IP, и, как правило, такое сканирование направлено на большое число IP-адресов. Ответной реакцией является идентификация источника и информирование владельца системы-источника о том, что его система, скорее всего, подверглась воздействию злоумышленника.
Сканирование портов. Сканирование портов используется для определения служб, работающих на системах сети. Системы обнаружения вторжений выявляют сканирование портов в случае, когда определенное число портов (соответствующее пороговому значению) на одной системе открывается в течение небольшого промежутка времени. Датчики NIDS и некоторые датчики HIDS обеспечивают идентификацию данного типа сканирования и составляют соответствующие отчеты. Ответные действия на сканирование данного типа идентичны ответным действиям на скрытое сканирование.
Сканирование "троянских коней". Существует множество вредоносных программ типа "троянский конь". Датчики NIDS содержат признаки, определяющие многие из этих программ. К сожалению, трафик, направленный на "троянские" программы, как правило, определяется конечным портом пакета. Это обстоятельство вызывает большое число ложных срабатываний системы обнаружения вторжений. В случае возникновения события "Trojan" следует проверять исходный порт трафика. К примеру, трафик, исходящий с порта 80, как правило, поступает с веб-сайта.
Одним из наиболее распространенных типов "троянского" сканирования является сканирование BackOrifice. Программа BackOrifice использует порт 31337, и очень часто злоумышленники осуществляют сканирование диапазона адресов для этого порта. Консоль BackOrifice также содержит функцию "ping host" (отправка пинг-запросов на узлы), которая осуществляет сканирование автоматически. Беспокоиться не о чем, пока не будет зафиксирован исходящий трафик с внутренней системы. Опять-таки, в данном случае нужно связаться с владельцем системы-источника, так как она, вероятно, подверглась воздействию злоумышленника.
Сканирование уязвимостей. Сканирование уязвимостей распознается системой IDS при обнаружении большого набора различных признаков атак. Как правило, такое сканирование направлено на несколько систем. Редки случаи, когда сканирование уязвимостей производится по отношению к диапазону адресов без активных систем.
Сканирование уязвимостей, осуществляемое хакерами, невозможно отличить от сканирования уязвимостей, проводимого компаниями, которые проверяют уровень защищенности информационных систем (во многих случаях в этих компаниях используются те же самые средства!). Так или иначе, само по себе сканирование не причиняет системе какого-либо вреда, однако если атакующий выполнил сканирование, в результате которого выявились системы с уязвимостями к атаке, ему после этого становится известно, какие системы можно атаковать. Для обеспечения соответствия компьютерных систем актуальным проблемам безопасности следует контактировать с владельцем системы-источника и проверять внутренние системы организации на наличие самых последних надстроек безопасности и обновлений.
Совет
Как правило, сложно отличить сканирование уязвимостей от атаки, так как IDS в обоих случаях инициирует одни и те же события. Разница здесь заключается в количестве событий. Сканирование уязвимостей, как правило, сопровождается большим числом различных событий за очень малый отрезок времени, в то время как при проведении атак происходят события одного типа.
Отслеживание файлов. Отслеживание файлов или проверка файловых разрешений, как правило, осуществляется внутренним пользователем. Пользователь пытается определить, к каким файлам можно осуществить доступ и что эти файлы могут содержать. Данный тип разведки распознается только датчиком HIDS и только в том случае, если в системе ведется журнал попыток несанкционированного доступа. Отдельные события подобного рода, как правило, представляют собой невинные ошибки, однако если прослеживается определенная схема, то следует связаться с пользователем и выяснить, что же произошло.
Атаки
События атак требуют самой быстрой ответной реакции. В идеальном случае IDS должна быть настроена только на идентификацию событий высокого приоритета в случае использования известной внутренней уязвимости. В этом случае должна быть немедленно применена процедура обработки инцидента.
Имейте в виду, что IDS не распознает разницу между непосредственной атакой и сканированием уязвимостей, которое выглядит как атака. Администратор системы IDS должен проводить оценку информации, представленной системой IDS, для определения того, является ли событие атакой. Во-первых, необходимо выяснить число событий. Если в течение короткого промежутка времени наблюдался набор признаков различных атак, то это, скорее всего, сканирование уязвимостей, а не непосредственная атака. Если же обнаружен один признак атаки, направленной на одну или несколько систем, то это событие может представлять собой настоящую атаку.
Нарушения политики
Большая часть систем IDS поставляется с признаками следующих событий.
- Общий доступ к файлам (Gnutella, Kazaa и т. д.).
- Обмен мгновенными сообщениями.
- Сеансы Telnet.
- Команды "r" (rlogin, rsh, rexec).
В большей части организаций использование такого трафика является нарушением политики безопасности. К сожалению, такие нарушения политики могут представлять для организации большую опасность, нежели непосредственные атаки. В большинстве случаев событие происходит в действительности. Таким образом, открывается доступ к файлам, и системы настраиваются на разрешение выполнения команды rlogin.
Выбор метода обработки различных нарушений политики зависит от внутренних политик и процедур, имеющих место в организации. Тем не менее, необходимо разъяснить все моменты системному администратору или ответственному лицу, чтобы ему стала ясна суть политик организации.
Подозрительные события
События, не соответствующие полностью ни одной из других категорий, заносятся в категорию подозрительных событий. Подозрительным событием называется событие, которое не удалось распознать.
Например, ключ реестра Windows NT был изменен по непонятной причине. Это не похоже на атаку, но в то же время не ясно, каковы причины изменения ключа. В качестве другого примера можно привести пакет с флагами заголовка, нарушающими стандарт протокола. Это может быть попытка разведывательного сканирования, результат неисправности сетевой карты системы или пакет, при передаче которого возникли ошибки. В данных, выдаваемых системой IDS, не предоставляется достаточно сведений для четкого определения конкретной ситуации и выяснения того, что произошло - безобидная ошибка или атака.
Ничуть не менее подозрительным может оказаться неожиданный сетевой трафик, появившийся во внутренней сети. Если рабочая станция начинает запрашивать SNMP-данные с других систем, то это может быть как следствием атаки, так и неправильной конфигурации. Подозрительные события необходимо исследовать настолько, насколько позволяют это делать имеющиеся ресурсы.
Внимание!
Исследование подозрительных событий может быть очень трудоемкой задачей. Нередко представляется разумным пропустить некоторые из этих событий или просто передать информацию сетевому или системному администратору.
Исследование подозрительных событий
При возникновении подозрительных действий следует выполнить процедуру, состоящую из следующих шагов, чтобы определить, является ли данное действие удавшимся вторжением или попыткой проникновения, либо оно носит безвредный характер. Итак, нужно выполнить следующие шаги.
- Идентифицировать системы.
- Записывать в журнал сведения о дополнительном трафике между источником и пунктом назначения.
- Записывать в журнал весь трафик, исходящий из источника.
- Записывать в журнал содержимое пакетов из источника.
При выполнении каждого шага необходимо определять, достаточно ли очевидных признаков для выяснения того, является ли данное действие атакой. В следующих разделах приводится описание данных шагов.
Примечание
При исследовании события необходимо иметь в виду следующий момент. Если событие происходит один раз и больше не повторяется, то очень трудно получить какую-либо дополнительную информацию (кроме того, откуда поступил трафик).
Одиночные аномалии исследовать практически невозможно.
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 присутствует в теле сообщения, то это определенно не попытка вторжения.
Понимание контекста события помогает определять ложные срабатывания.
| SUS_ACT | Уведомление, занесениев журнал | Источник подозрительной активности | Пункт назначения подозрительной активности | TCP,UDP и/или ICMP, в зависимости от типа обнаруженной активности | Любой | Любой |
Теперь зададимся вопросом, что же это все нам дает. Во-первых, мы получаем представление о другом трафике, имеющем место между источником и пунктом назначения. Если бы пакет WIZ был единственным трафиком между двумя системами, из этого можно было сделать вывод о том, что это похоже на попытку проникновения в систему. Напротив, если наблюдается большое число трафика SMTP (почты) между двумя системами, то, скорее всего, это обычный легитимный почтовый трафик.
3. Запись в журнал всего трафика из источника
Подразумевая, что данных, фиксируемых посредством записи всего трафика между двумя системами, недостаточно для определения того, является ли активность легитимной, можно начать сбор другого трафика, поступающего с источника. Имейте в виду, что объем этого трафика может быть ограниченным. Если источник подозрительной активности находится в некоторой удаленной сети, то будет наблюдаться только трафик, поступающий на ваш узел. Если же источник локальный, то возможен сбор всего трафика с данного компьютера, что даст гораздо более широкое представление о том, что же на самом деле происходит.
Чтобы начать сбор всего трафика с источника, настройте детектор IDS на сбор всей информации из подозрительного источника. Пример такой конфигурации приведен в таблице 13.4.
| SUS_SRC | Уведомление, запись в журнал | Источник подозрительных действий | Любой | TCP,UDP и/или ICMP, в зависимости от типа обнаруженной активности | Любой | Любой |
Такая конфигурация, как правило, генерирует некоторую информацию, не представляющую какой-либо ценности для исследования. До тех пор, пока возможна объективная оценка информации, данный журнал можно использовать для составления подробной картины происходящих взаимодействий, имеющих место между источником и пунктом назначения. Попытайтесь вникнуть в суть наблюдаемой активности. Является ли наблюдаемая активность веб-трафиком? Исходит ли трафик из подозрительного источника, или же его источником является ваш узел?
На данном этапе исследования должна быть известна следующая информация.
- Имя системы-источника.
- Тип и частота трафика, обмен которым происходит между источником и пунктом назначения.
- Тип и частота трафика, обмен которым происходит между источником и любыми другими системами вашего узла.
Эта информация обеспечивает достаточно подробное представление о природе подозрительного трафика. Тем не менее, степень очевидности происходящего может не сказать о том, является ли наблюдаемая активность попыткой атаки.
4. Запись в журнал содержимого пакетов из источника
Конечным шагом проводимого исследования является запись в журнал содержимого пакетов, исходящих из источника. Следует заметить, что данный подход полезен только при работе с текстовыми протоколами, такими как telnet, FTP, SMTP и HTTP (в некоторой степени). Если используются двоичные протоколы или протоколы с шифрованием, данный подход совершенно бесполезен. Для реализации описанного метода необходимо изменить конфигурацию IDS, как показано в таблице 13.5.
Посредством занесения в журнал содержимого пакетов можно составить полную запись сеанса, а также зафиксировать команды, непосредственно отправляемые в пункт назначения.
После фиксирования некоторых данных необходимо просмотреть найденную информацию. Обозначает ли сеанс потенциальную атаку, или же все выглядит в пределах допустимого? Скомбинировав эти данные с другой найденной информацией, можно найти ответ на этот вопрос. Если этого сделать не удалось, попытайтесь найти человека, у которого есть опыт работы с исследуемым протоколом.
| SUS_ACT | Уведомление, запись в журнал содержимого пакета | Источник подозрительной активности | Пункт назначения подозрительной активности | TCP или UDP | Любой | Порт, на который направлен подозрительный трафик |
| SUS_ACT | Увеомление, запись в журнал содержимого пакета | Пункт назначения подозрительной активности | Источник подозрительной активности | TCP илиUDP | Порт, на который направлен подозрительный трафик | Любой |
