Требования к СОН

Необходимо отметить, что СОН могут применяться как к авторизованным пользователям системы, использующим ее некорректно (т.е. нарушающим ее политику безопасности), так и к внешним по отношению к системе пользователям (нарушителям).

СОН должна выполнять следующие основные функции:

· Контролировать и анализировать активность пользователей и вычислительной системы;

· Фиксировать конфигурации системы и уязвимости;

· Оценивать целостность критических системных файлов и файлов данных;

· Распознавать шаблоны активности, отражающие известные атаки;

· Проводить статистический анализ для выявления аномального поведения;

· Распознавать нарушения политики безопасности пользователем системы;

Кроме вышеописанных основных функций СОН должна в идеале удовлетворять следующим функциональным характеристикам:

1. Выполняться непрерывно с минимальным вмешательством пользователя.
2. Быть защищена от сбоев, т.е. не зависеть от сбоев системы, произошедших случайно или вследствие действий нарушителя.
3. Контролировать собственную целостность и обнаруживать собственные модификации, осуществленные нарушителем.
4. Минимально воздействовать на систему, безопасность которой контролируется.
5. Конфигурироваться в соответствии с политикой безопасности контролируемой системы.
6. Адаптироваться к изменениям в системе и поведении пользователя во времени (новые приложения, новые ресурсы, санкционированные изменения активности пользователя).
7. Работать с данными, поступающими от многих пользователей.
8. Поддерживать динамическую реконфигурацию.
9. Обеспечивать администратора системы данными достаточными для восстановления системы после атаки.

Как следствие данных требований желательно строить систему обнаружения нарушителя по архитектуре клиент-сервер.

Задачи решаемые системами обнаружения нарушителя. Глобальная задача – распознавание нарушителя и законного пользователя. Решаемые при этом задачи:

1. сбор данных;
2. фильтрация данных;
3. классификация поведения – непосредственно процесс распознавания нарушителя;
4. отчет;
5. отклик системы.

Первый опыт построения системы обнаружения нарушителя.

В первой работе, посвященной проблеме обнаружения нарушителя, в 1986 году Дороти Деннинг описала СОН IDES структура которой показана на рисунке 1.

Рисунок 1. Типовая схема функционирования СОН.

Показанная на данном рисунке структура является в некотором роде “классической”, т.к. отражает общие принципы построения многих СОН.

Для описания процесса обнаружения нарушителя используются записи аудита, профили, аномальные записи и правила действия.

Субъекты и объекты.

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

Записи аудита

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

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

<субъект, объект, действие, ошибка, ресурс, время>.

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

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

<joe, myfile, execute, no, CPU (00:02), 2:00>

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

<joe, important_file, read, no, CPU (00:01), 5:00>

<mik, important_file, read, no, CPU (00:01), 5:01>

<scr, important_file, read, no, CPU (00:01), 5:02>

<lee, important_file, read, no, CPU (00:01), 5:03>

Это, конечно, будет означать, что многие различные пользователи систем по какой-либо причине, заинтересованы в прочтении файла important_file.

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

Профили.

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

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

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

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

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

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

<субъект, объект, действие, е_образец, r_образец, t_образец>.

Для такого профиля в качестве особого условия оговаривается, что как только субъект инициирует действие некоторым объектом предполагается, что условиями ошибками является е_образец, для использования ресурсов служит r_образец, а для продолжительности времени - t_образец. Например, может иметь место создания следующего профиля:

<joe, myfile, execute, no, CPU (00:01-00:04), 2:00-22:00>

Это означает, что всякий раз, когда joe использует myfile, не ожидается никаких ошибок, можно использовать от 1 до 4 секунд процессорного времени, а время работы должно быть в пределах от двух часов ночи (т.е. 2:00) до 10 часов вечера (т.е. 22:00). Аналогичные профили можно создать и для других действий, касающихся безопасности, таких как входы в систему.

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

Аномальные записи

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

<события, время, профиль>.

В структуре этой аномальной записи поле “событие” указывает на действие системы, которое вызвало сигнал тревоги, поле “время” указывает, когда проблема была замечена, а поле “профиль” указывает не совпавшую структуру (поскольку в системе, вероятно, много профилей).

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

· Поведение, подозрительное по отношению к любому пользователю системы.

· Поведение, подозрительное по отношению к какому-то особому пользователю системы.

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

Правила действия.

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

Правила действия обычно кодируются в форме длинных условных выражений вида:

if тревога (0) then действие (0)

if тревога (1) then действие (1)

........

if тревога (n-1) then действие (n-1)

Применение рассмотренной модели дало хорошие результаты. Вместе с тем требуют исследований такие вопросы:

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

Структура системы обнаружения нарушителя.

Обобщение опыта построения СОН было сделано в документе “Единая структура систем обнаружения нарушителя”. В данном документе определено множество компонентов, образующих СОН:

· генератор событий (E-box);

· модуль анализа (A-box);

· модуль хранения (D-box);

· модуль контрмер (C-box).

На рисунке 2 показана взаимосвязь компонентов СОН.

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

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

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

Многие СОН построены так, что в ответ на атаку, они выдают только сигнал тревоги. Однако, коммерческие системы часто имеют в своем составе модуль контрмер. Данный модуль может по желанию пользователя СОН автоматически запускать некоторый процесс, закрывать соединение TCP или модифицировать конфигурацию МЭ с целью предотвращения дальнейших атак.

Говоря об архитектуре СОН невозможно обойти вниманием вопрос о периодичности работы СОН.

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

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

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

В следующих параграфах рассмотрим модули СОН подробнее.

Модуль сбора и фильтрации данных.

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

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

Кроме записей аудита система обнаружения использует следующие данные:

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

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

Можно привести следующие схемы аудита:

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

В зависимости от типов предполагаемых атак можно предложить следующие методы аудита для СОН хоста.

1. Аудит входа в систему; собирает данные о том, кто, когда и как вошел в систему. При этом целесообразно фиксировать:

· имя пользователя, вошедшего в систему;

· наименование терминала или удаленного хоста, с которого был осуществлен вход в систему;

· время входа и выхода пользователя.

2. Аудит процессов; собирает данные о том, какие сервисы системы были использованы. При этом целесообразно фиксировать:

· условия исполнения (используются ли права суперпользователя) процесса;

· значение, возвращаемое процессом при завершении;

· имя пользователя и группы;

· терминал, с которого запущен процесс;

· время вызова процесса;

· время, проведенное в режиме пользователя;

· время, проведенное в режиме ядра;

· общее время выполнения;

· средняя использованная память;

· количество обработанных символов;

· количество считанных – записанных блоков информации;

· имя команды для запуска процесса.

3. Аудит ошибок и административных данных.

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

Пример топологии сети, использующей СОН сети приведен на рисунке 3.

Библиотека Libcap является свободно-распространяемой библиотекой сбора сетевых пакетов. Данная библиотека обеспечивает ПО независимостью от технологии построения сети (Ethernet, FDDI, SLIP и т.д.), что способствует переносимости данной библиотеки на различные программно-аппаратные платформы и, как следствие, популярность данной библиотеки. Libcap обладает возможностью фильтрации данных на основе установки фильтра, такого как BPF, который позволяет отбрасывать многие сетевые пакеты, не передавая их ядру.

Одной из основных проблем сетевых СОН является быстродействие, т.к. лучшие из них в состоянии функционировать при пропускной способности сети около 100Мбт, но не могут обеспечить нормальное функционирование в гигабитных сетях.

В данном параграфе объединим перечисление данных аудита, которые нам необходимо снимать для обнаружения удаленных атак, с характеристиками семейства протоколов TCP/IP.

ARP запрос

· IP адресом источника;

· аппаратный адрес источника;

· сетевой интерфейс ограничивающий ARP запрос.

IP-фрагмент.

· адрес источника;

· адрес приемника;

· поле протокола;

· поле смещения;

· длина;

· длина заголовка;

· MF бит;

· идентификация.

IP датаграмма

· сообщение о перекрытии фрагмента;

· содержимое фрагмента при перекрытии.

ICMP сообщение

· IP адрес источника;

· IP адрес приемника;

· ICMP поле типа;

· ICMP идентификатор;

· ICMP номер последовательности.

TCP пакет

· IP адрес источника;

· IP адрес приемника;

· TCP порт источника;

· TCP порт приемника;

· бит кода TCP.

TCP модуль

· переходы из состояния LISTEN в состояние SYN_RECVD;

· переходы из состояния SYN_RECVD в состояние LISTEN;

· переходы из состояния SYN_RECVD в состояние CONNECTED;

· сравнение полуоткрытых соединений с числом возможных соединений.

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

Фильтрация данных – анализ данных с целью выявления наиболее значимых компонентов данных для уменьшения времени обработки и места для хранения. Фильтрация данных необходима для:

· повышения эффективности анализа;

· уменьшения загрузки сети при передаче данных между модулями СОН;

· уменьшением места необходимого для хранения данных.

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

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

Фильтрация данных должна проводиться осторожно, т.к. могут быть отброшены важные для анализа данные. В таких системах как DIDS, MIDAS, TIM, NSM данные фильтруются на основе эвристик (экспертных правил), которые могут быть просмотрены и отредактированы.

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

Преимуществом сетевых СОН является:

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

· анализ пакетов - сетевые СОН анализируют все пакеты, проходящие через них на предмет наличия подозрительных действий; только на основании данного анализа могут быть обнаружены современные атаки, связанные с отказом в обслуживании (СОН хоста не в состоянии обнаружить атаки данного типа);

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

· обнаружение и отклик в реальном времени - сетевые СОН распознают атаки и реагируют на них в режиме реального времени (для СОН хоста отклик на нарушение часто приходит уже тогда, когда нарушение состоялось);

· обнаружение намерения вторжения - сетевые СОН могут использоваться для обнаружения намерения вторжения. Это достигается, например, помещением СОН вне области, защищаемой МЭ (при этом атаки на хосты внутренней сети фиксируются на СОН, но не проходят через МЭ). СОН хоста не обладают такой возможностью. На основании обнаружения намерения вторжения можно получить такую интересную статистику, как частоту и типы атак на систему.

· дополнение и верификация существующих механизмов защиты – сетевые СОН могут дополнять существующие механизмы защиты; использование в сети механизмов шифрации не позволяет СОН обнаруживать атаки в зашифрованном трафике; однако, СОН могут обнаруживать трафик, остающийся незашифрованным; при применении МЭ СОН позволяет верифицировать его функционирование;

· независимость от типа ОС - сетевые СОН в первом приближении не зависят от типа ОС, функционирующих на хостах сети.

Преимуществами СОН хоста является:

· верификация атак – базируясь на данных аудита, СОН хоста анализируют события, которые действительно произошли в системе, что дает преимущество при анализе, т.к. имеется информация об успехе или неудаче атаки. Это приводит к большей точности определения атак, и, соответственно, к меньшему числу ложных срабатываний (сетевые СОН характеризует большой процент ложных срабатываний, т.к. нормальный трафик очень часто похож на трафик, содержащий атаку; кроме того сетевое СОН не имеет информации об успехе атаки);

· активность на хосте - СОН хоста может легко отслеживать активность на хосте, т.е. действия пользователей, доступ к файлам, вход и выход из системы и т.д. (сетевое СОН не имеет возможности отследить данную активность); сетевые СОН так же неспособны определить изменения в политике безопасности системы.

· использование шифрации – применение шифрации при передаче данных по сети может создавать трудности для работы сетевых СОН; СОН хоста не имеют данной проблемы, т.к. базируются на данных аудита, содержащих незашифрованные данные;

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

· отсутствие необходимости использования дополнительного аппаратного обеспечения – СОН не требует дополнительного аппаратного обеспечения для обнаружения нарушителя, т.к. обычно выполняется на защищаемых объектах сети, что делает их в некоторых случаях более эффективными, чем СОН сети;

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

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

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

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

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

Модуль реакции

При обнаружении атаки СОН может выполнить следующие действия:

· переконфигурировать МЭ, заблокировав IP адрес, с которого была осуществлена атака;

· выдать звуковой сигнал;

· записать соответствующее событие в системный журнал;

· послать SNMP Trap на консоль администратора;

· послать e-mail сообщение администратору;

· послать сообщение на пэйджер администратору;

· записать информацию об атаке (время, IP адрес нарушителя, IP адрес / порт цели атаки, информацию о протоколе);

· записать данные атаки (поток пакетов) для дальнейшего анализа;

· запустить определенную программу;

· оборвать TCP соединение посылкой FIN пакета.